質疑応答より Q:サーバー/インフラエンジニアとビジネス側の連携はどのくらい取れているでしょうか? A:分かれていないというか、結構密、そうとう密。 Q:websocketでおくってるopus圧縮した音声データは1パケットどのくらいのデータ量ですか。 A:かなり変動します。通信状況によって溜めるなど。



from Twitter https://twitter.com/o_ob

まとめです ・マネージドサービスを積極的採用 ・ロックインを避ける ・技術の固定化をしない 変化に対して柔軟、変化に対して柔軟に。 PR: 採用関係はこちら↓ https://j.mp/3lIlKPX https://j.mp/3jMDFDz



from Twitter https://twitter.com/o_ob

ライブ配信データのパイプラインと 音声アーカイブ(デカい) ・Streaming Pipeline→Opus→Oggコンテナ→Cloud Storage 同時配信数の増加→比例して処理データ量増→Cloud Dataflow側で吸収してくれる→追加オペレーションなし・データロストの発生もなし すごい https://j.mp/3buA61S



from Twitter https://twitter.com/o_ob

先ほどのライブ配信データからのパイプライン構成 ・Apache Beam Java SDK ・Cloud DataFlow Streaming ・監査用音声アーカイブファイル生成 https://j.mp/2EMjYgi



from Twitter https://twitter.com/o_ob

この構成によって更なる横展開効果が。 事例1:コラボ配信サーバ ・アバタービデオチャット的なコンポーネント ・ボイスチャットの音声ミキシング 事例2:ゲーム配信サーバ ・ゲームサーバ+ゲーム配信の視聴サーバの機能 https://j.mp/2F008hi



from Twitter https://twitter.com/o_ob

Node.js Redis Pub/Sub スケーラビリティに問題がある 分散させると…エンドポイントレベルのシャーディング、運用コストが高い。 https://j.mp/2ESqLoC



from Twitter https://twitter.com/o_ob

続いて「ライブ配信基盤」について増住さんから ・Websocket ・Protobuf形式でシリアライズ ・配信データのボリュームが大きい ・パトロール・監査のために参照可能な方式で保存する必要がある →配信音声やラベル付き配信データ https://j.mp/2QQTUTy



from Twitter https://twitter.com/o_ob